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J  Real  time  mixtion-oriented  embedded  systems  are  much 
more  difficult  to  design  than  ordinary  software  systems.  They 
require  highly  reliable  and  efficient  implementations  to  satisfy 
miaaioo  and  time  constraints  imposed  by  the  applications.  The 
Ada  language  has  been  design  to  facilitate  real  time  system 
software  development.  However,  for  many  programmers  the  size 
mA  complexity  of  Ada  itself  are  of  concern. 

In  the  assertive  programming  paradigm,  computations  are 
specified  as  sets  of  aaaertioos  about  properties  of  the  solution, 
and  not  aa  a  of  procedural  steps.  Solving  procedures 

are  automatically  generated  from  the  assertive  description.  Real 
time  programming  for  tnurion-orteraed  systems  is  supported  by 
equations!  languages  in  which  assertions  are  expressed  as  alge¬ 
braic  equations  Programs  written  in  equational  languages  are 
concise,  free  fttxn  implementation  details,  and  easily  amenable  to 
verification  and  parallel  processing.  The  level  of  programming 
expertise  required  to  program  in  an  equational  language  is  much 
lower  than  the  level  that  is  needed  by  Ada  programmers 


The  paper  describes  an  implementation  of  an  equational 
language  system  which  generates  highly  efficient  distributed  code 
in  Ada.  It  also  demonstrates  how  the  equational  language  system 
can  be  used  in  real  time  software  development. 


1.  INTRODUCTION 

Real  time  system  programming  is  distinct  from  pro¬ 
gramming  other  parallel  or  distributed  applications  in  that 
timing  constraints  are  imposed  on  delays  caused  by  real 
time  programs.  The  complexity  and  diversity  of  skills 
needed  for  real  time  programming  have  caused  extended 
development  times,  difficulties  in  attaining  desired  reliabil¬ 
ity  and  sometimes  even  a  reluctance  to  undertake  mainte¬ 
nance  and  updating  of  teal  turns  systems.  This  has 
motivated  development  of  several  programming  languages 
[Brinch  1978.  1981,  Martin  1978,  Wirth  1977,  and  most 
notably  Ada,  1978]  to  make  die  task  easier. 

Real  time  system  development  can  often  be  simplified 
if  it  is  done  on  higher  programming  level  then  supported  by 


expressed  as  a  set  of  assertions  about  properties  of  the  solu¬ 
tion  and  not  as  sequence  of  procedural  steps. 

In  the  paper,  we  discuss  the  design  of  an  Ada  code 
generator  for  the  assertive  language  called  MODEL  [Tseng 
et  al,  1986].  Assertions  in  MODEL  are  expressed  as  recur¬ 
sive  equations.  MODEL  specifications  are  concise,  free 
from  implementation  details,  and  easily  amenable  to 
verification  and  parallel  processing. 

The  MODEL  language  and  system  aid  or  automate  the 
following  steps  of  the  software  development  and  mainte¬ 
nance  process: 

1.  Generating  high  level  language  code  for  individual 
program  units.  A  very  high  level,  nonprocedural 
language  (MODEL)  is  provided  for  writing  the 
software  specifications.  The  MODEL  compiler  uses 
specifications  to  generate  program  code  in  Ada  or 
other  high  level  programming  language  (Fortran,  C  or 
PU1). 

2.  Establishing  synchronization  and  communication 
between  program  units  executing  in  parallel.  The 
Configuration  Specification  Language  (CSL)  is  pro¬ 
vided  for  this  purpose.  A  MODEL  subsystem  called 
Configurator  generates  communication  tasks  with 
necessary  entries. 

3.  Testing.  An  executable  model  of  the  system  that  runs 
on  the  host  computer  is  produced  by  the  MODEL 
compiler  and  Configurator.  This  model  can  be  used  for 
testing,  debugging  and  performance  study  purposes. 

4.  Documenting.  Several  reports  are  generated  automati¬ 
cally.  The  following  is  a  partial  list:  the  system  design 
and  structure,  individual  program  listing,  generated 
Ada  (or  Fortran,  C,  or  PU1)  code  listing  and  tinning 
reports. 


Ada.  Several  specification  languages  [Lamport  1983,  Laner 
1979,  Lee  1986,  Milner  1980,  Ramimrithan,  Teichreow 
1977,  Zave  1982]  have  been  proposed  to  this  end.  Some  of 
these  languages  support  assertive  programming  paradigm 
which  provide  a  bridge  between  the  formal  requirements  of 
a  teal  rime  system  and  the  system  implementation  (for 
example  in  Ada).  In  this  paradigm  a  computation  is 


5.  Static  timing  performance  analysis.  Normally,  the  tim¬ 
ing  study  can  be  done  only  after  programs  in  target 
machine  code  have  been  produced  and  executed. 
Instead,  with  the  help  of  a  MODEL  subsystem  called 
timing  evaluator,  performance  analysis  can  be  done 
when  an  individual  task  has  been  specified,  even  on  a 
host  other  than  the  target  machine. 
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The  paper  discussea  aa  implementation  of  the  Ada 
code  feneruor  far  the  MODEL  tynem.  It  ia  crpaized  u 
follow*.  In  the  next  section,  ««  describe  real  tune  software 
development  using  MODEL.  Section  3  discusses  implemen¬ 
tation  of  the  Configurator  and  generation  of  communication 
tasks.  Section  4  describes  Ada  code  generation  for  program 
units.  Finally,  the  last  section  offers  the  conclusion  regard¬ 
ing  the  use  of  equadooal  languages  for  real  time  program¬ 
ming. 

2.  REAL  TIME  SYSTEM  DEVELOPMENT  USING 
MODEL 

In  the  MODEL  approach,  the  programmer  initially 
partitions  the  problem  into  units  based  on  functional 
affinity.  Then,  each  unit  function  is  described  in  the 
MODEL  equahooal  language.  A  series  of  translators  is 
employed  to  implement  the  computation  and  provide  the 
feedback  on  performance.  This  guides  the  programmer  in 
further  panitiooing  or  consolidating  parallel  units  until  s 
satisfactory,  locally  optimal,  performance  is  reached. 

Three  software  tools  were  developed  to  support  our 
approach: 

i)  A  compiler  for  the  configuration  specification  language 
in  which  units'  interconnections  and  a  mapping  of  the 
parallel  tasks  onto  processors  are  defined. 

ii)  A  compiler  for  the  MODEL  equational  language  in 
which  individual  units  are  defined.  This  compiler  pro¬ 
duces  parallel  tasks  for  the  respective  processors. 

iii)  A  timing  evaluator  far  estimating  the  delays  inherent 
in  the  parallel  tasks.  The  estimates  are  used  by  the 
programmer  to  verify  that  the  time  constraints  of  the 
developed  system  are  satisfied. 

The  real  time  software  development  process  starts 
after  die  software  system  requirement  are  available.  These 
requirements  usually  consist  of  three  parts  : 

1.  Functional  requirements  -  defining  the  functions  and 
subfunctions  of  the  system. 

2.  Performance  requirements  •  time  constraints  for  time- 
critical  performance  of  the  system. 

3.  Definition  of  interfaces  with  the  environment  -  the  lay¬ 
out  of  the  data  communicated  with  the  environment. 
The  programmer  begins  by  dividing  the  system  func¬ 
tions  into  software  units  and  data  files.  A  function  may  be 
carried  out  by  one  one  or  more  units,  or  several  related 
functions  may  be  combined  into  one  unit.  The  relationship 
and  communications  between  units  are  also  defined  at  this 
point  The  program  units  are  in  skeletal  form,  with  only  the 
external  data  structures  outlined  as  files.  The  programmer 
can  now  use  the  Configurator  to  verify  global  system  con¬ 
sistency  and  completeness. 

Next  the  programmer  composes  the  unit  specifications 
independently  for  each  program  unit  in  the  MODEL 


language.  The  MODEL  compiler  processes  each  unit 
separately,  performing  completeness  and  consistency  checks 
within  each  unit  and  in  the  absence  of  errors,  generates  an 
Ada  program  to  perform  the  task  of  that  unit  The  user  can 
now  employ  the  Tutting  Evaluator  on  each  generated  Ada 
program  to  verify  whether  the  time  constraints  associated 
with  the  corresponding  program  unit  are  satisfied.  The  Tun¬ 
ing  Evaluator  produces  a  Tutting  Report  for  each  program 
unit  that  provides  information  on  time  delays  between 
instances  of  input  and/or  output  in  the  unit  The  user  has  to 
provide  certain  tinting  data  of  the  target  machine  to  the 
Tuning  Evaluator  for  it  to  generate  the  Tinting  Report 

The  programmer  may  also  have  to  check  if  global 
time  constraints  are  met  by  adding  individual  unit  delays  in 
a  path  of  the  configuration  to  obtain  the  overall  delays 
between  critical  events  involving  multiple  units.  If  some  of 
these  constraints  are  not  the  programmer  may 

have  to  modify  the  configuration  of  the  entire  system  by 
partitioning  some  units  to  obtain  a  greaser  degree  of  paral¬ 
lelism. 

Once  all  the  program  units  have  been  satisfactorily 
processed  by  the  MODEL  compiler  and  the  tinting  evalua¬ 
tor,  the  programmer  uses  the  Configurator  to  synthesize  all 
the  system  components  (units  and  data  files)  into  an 
integrated  system.  The  user  composes  the  system  by  speci¬ 
fying  a  configuration  of  units  and  files  in  the  Configuration 
Specification  Language  that  is  input  to  the  Configurator.  It 
then  schedules  individual  program  units,  synchronizes  units 
that  will  execute  in  parallel,  generates  tasks  responsible  for 
exchanging  communications,  and  generates  a  configuration 
procedure  that  will  run  the  Ada  programs  with  maximum 
concurrency  in  the  host  computer’s  multiprogramming  / 
multiprocessing  environment 

Finally,  the  system  can  be  executed  and  tested  on  the 
host  machine.  Then,  code  can  be  transferred  to  the  target 
machine  for  further  testing  and  execution. 

3.  CONFIGURATION  SPECIFICATION  LANGUAGE 

The  Configuration  Specification  Language.  CSL, 
defines  flow  of  data  between  program  units.  Objects  of  the 
language  are  units  and  files  that  the  units  exchange  [Shi  et 
al,  1987],  A  target/source  or  consumer/producer  relationship 
between  a  file  (file)  and  a  unit  is  represented  by  a  directed 
edge  between  those  objects.  When  the  same  file  is  pro¬ 
duced  by  one  unit  and  consumed  by  another,  then  these  two 
units  become  connected  via  the  file. 

Two  attributes  of  configuration  nodes  are  worth  of 
mentioning  here.  A  unit  type  shows  whether  the  unit  is: 

1)  simple  -  an  individually  specified  unit  (default), 

2)  compound  -  a  group  of  units  for  which  a  configuration 

is  defined  separately,  or 

3)  interactive  -  a  human  communicating  with  the  system 

through  a  terminal. 
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Files  have  an  organization  attribute  with  the  following 
values:  sequential  (default),  intWnt,  mail  and  post 

A  sequential  file  is  exchanged  as  one  entity.  It  can  be 
consumed  only  after  it  has  bees  entirely  produced.  Such  a 
file  may  have  only  one  producer,  U>  any  number  of  consu¬ 
mers. 

An  indexed  file  has  a  variable  defined  as  a  key  used  to 
define  (access)  records  in  the  file.  There  are  no  restrictions 
on  the  order  or  number  of  references  to  such  a  file  made  by 
producers  and  consumers. 

A  mail  file  is  a  collector  of  records.  It  is  private  to  its 
consumer  and  therefore  it  can  have  only  one  consumer,  but 
several  producers.  Records  from  different  producers  are 
accepted  by  the  consumer  in  order  of  their  arrival. 

A  post  file  is  a  distributor  of  records  to  dynamically 
addressable  files.  The  post  file  has  one  producer,  and  its 
record  include  a  key  used  as  an  address  of  a  destination 
file.  Therefore,  it  can  have  any  number  of  edges  connect¬ 
ing  it  to  mail  files. 

An  exchange  of  data  between  units  executed  in  paral¬ 
lel  can  be  set  either  through  a  mail  file  or  a  pair  of  a  post 
and  mail  files  connected  together.  The  goal  of  our 
approach  is  to  eliminate  timing  considerations  from  teal 
time  programming.  The  user’s  view  of  computation  is 
totally  static,  where  computation  itself  is  expressed  as  a 
mapping  of  source  data  structures  onto  target  data  struc¬ 
tures.  Consequently,  our  communication  primitives  are 
based  on  (limited)  nonblocking  'send'  and  blocking 
’receive’.  The  producer  of  the  messages  continues  compu¬ 
tation  immediately  after  of  messages  waits  until  the  mes¬ 
sage  to  be  read  arrives.  Such  semantics  allows  the  user  to 
treat  communications  in  exactly  the  same  way  as  ocher  i/o. 
If  the  synchronization  is  needed,  it  can  easily  be  achieved 
by  adding  a  ’receive’  (in  the  producer  unit)  after  the  ’send’ 
to  obtain  an  answer  (or  an  acknowledgement)  from  the  con¬ 
sumer. 

The  MODEL  compiler,  when  generating  a  program  for 
a  unit,  optimizes  the  use  of  the  main  memory  assigned  to 
data,  often  replacing  the  entire  range  of  an  array  by  a  win¬ 
dow,  i.e.  few  elements.  When  such  array  has  to  be  com¬ 
municated  to  the  other  units,  only  that  window,  i.e.  few 
records  at  a  time,  can  be  sent  out.  Therefore  program 
optimization  causes  a  producer  to  store  or  send  as  few 
records  at  a  time  as  feasible.  Similarly,  a  consumer  has 
also  to  store  and  consume  a  minimum  number  of  records  at 
a  time.  When  producer  and  consumer  processes  are  con¬ 
current,  the  post  and  mail  files  require  a  buffer  for  a  limited 
number  of  records.  This  type  of  data  exchange  realizes  the 
concept  of  a  pipeline  or  a  stream.  The  user  is  not  involved 
in  this  aspect  of  program  design,  however  is  warned  if  a 
file  can  not  be  exchanged  in  that  fashion. 

The  units  (processes)  and  files  are  the  basic  building 
blocks  of  a  system  in  the  MODEL  environment.  A  system 


can  be  easily  modified  by  composing  a  new  configuration 
that  includes  existing,  as  well  as  new  or  modified,  units  and 
files. 

The  easy  modifiability  of  a  configuration  supports 
several  development  modes.  For  example,  individual  units 
and  files  may  be  reused  as  the  system  is  required  to  change. 
Entire  independently  developed  systems  may  be  easily 
interconnected  by  adding  interfacing  processes  that  convert 
commonly  used  variables  from  the  form  used  in  one  system 
to  that  of  the  other.  Thus,  the  creation  of  a  new  system 
that  encompasses  the  functions  of  several  old  systems 
would  not  require  designing  of  a  new  system. 

Ada  implementation: 

Using  Ada  as  an  object  language  of  the  MODEL  sys¬ 
tem  gave  us  several  advantages  over  using  other  high  level 
languages.  Ada  multitasking  and  rendezvous  create  a  con¬ 
venient  tool  for  assembling  parallel  computations.  Each 
MODEL  specification  is  translated  into  a  task. 
Configuration  dependent  pans  of  program  units,  like  inter¬ 
connections,  are  encapsulated  into  separately  compiled  sub¬ 
programs  and  subtasks.  A  configuration  unit,  also  generated 
by  the  configurator,  assembles  the  parallel  computation  by 
simply  enumerating  in  its  body  all  the  participating  units 
with  the  ’WITH’  clause.  Only  configurator  generated  para 
of  the  overall  computation  have  to  be  recompiled  if  the 
configuration  changes. 

In  our  design  of  an  Ada  implementation  of  the 
MODEL  specifications,  we  stressed  the  independence  of 
computation  and  configuration  descriptions.  Units  generated 
by  the  MODEL  compiler  need  to  be  compiled  in  Ada  only 
once.  The  naming  can  be  local  in  program  units,  and  the 
configuration  provides  the  translation  of  file  names  in 
different  units.  The  user  is  able  to  select  any  set  of  such 
units  and,  after  providing  a  configuration  specification,  gen¬ 
erate  a  configuration  unit  that  will  run  the  entire  computa¬ 
tion.  The  configuration  unit  is  compiled  separately  from 
MODEL  units.  Any  change  in  configuration  unit  does  not 
require  MODEL  units  recompilation.  Such  solution  pro¬ 
vides  high  degree  of  modularity  and  supports  easy  assem¬ 
bling  of  new  systems  from  existing  computational  units. 
Thus,  it  facilitates  fast  prototyping  and  bottom-up  develop¬ 
ment  and  debugging  of  real-time  systems. 

The  devised  scheme  of  compilation  is  as  follows: 

Each  mail  file  is  replaced  by  a  task.  This  task  receives 
messages  from  producers,  stores  them  in  a  queue  and  then, 
on  the  consumer  request,  moves  them  to  the  consumer. 
Sender  and  consumer  establish  rendezvous  with  this  task 
and  not  directly  with  each  other.  Due  to  the  name  indepen¬ 
dence  (the  same  file  can  be  named  differently  in  different 
program  units),  sending  messages  is  done  through  a  re- 
router  procedures  which  are  generated  by  the  Configurator. 
These  procedures  contain  configuration  sensative  address 
tables. 
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The  generated  ADA  units  are  as  follows: 

A.  Each  MODEL  specification  of  a  program  unit  is  com¬ 
piled  by  the  MODEL  compiler  into  a  group  of  the  fol¬ 
lowing  packages- 

2.  Packages  for  each  source  mail  file  in  the  follow¬ 
ing  format: 


-  SMA1LN  •  source  mail  file  name 

-  UNTTN  -  name  of  the  unit  with  SMAILN 
package  UNITN.SMAILN  is 

task  UNITN_SMAILN_mbx  is 
entry  -•  for  receiving  mail 
entry  --  for  sending  mail 
end  UNITN_SMAILN_mbx; 
end  UNITNSMAILN; 
package  body  UNITN„S MAILN  is 
task  body  UNTTN_SMAILN_mbx  is 
--  body  of  the  mailbox  (queue  of  messages) 
end  UNITN_SMAILN_mbx; 
end  UNTTN_SMAILN; 


2.  A  package  for  a  unit  procedure  with  the  follow¬ 
ing  structure: 


-  SMAILN  -  source  mail  file  name 

-  TMAILN  -  target  mail/post  file  name 

-  UNTTN  -  program  unit  name 
with  SMAILNJJNITN;  -  repeat 

-  for  each  source  mail  file  in  the  unit 
package  UNTTN  is 

procedure  UNITN_prog; 

end  UNTTN; 

package  body  UNTTN  is 

procedure  UNITN_TMAILN_c  is  separate; 

-  repeat  for  all  post  and  mail  files 
procedure  UNITN_prog  is 

task  UNITN.tsk; 
task  body  UNITN_tsk  is 

-  code  of  the  MODEL  program  unit 
end  UNITN.tsk; 

begin 

null; 

end  UNITN_prog; 
end  UNTTN; 

B.  The  configurator  produces  the  following  configuration 
units: 

1.  For  each  target  post  or  mail  file  in  the 
configuration  it  will  generate  the  re-router  in  the 
form: 


—  TMAILN  -  target  mail/post  file 

-  UNTTN  -  program  unit  name 
with  UNITN;  -  repeat 

-  for  all  consumer  units 

separate  (UNITN)  --  name  of  program  unit 
-  which  contains  this  file 
procedure  UNITN_TMAILN_c  is 
begin 

-  a  table  of  address  translation  and 

-  case  on  the  value  of  the  table  address, 
end  UNITN_SMAILN_s; 

2.  A  configuration  unit  for  invoking  the  entire  com¬ 
putation: 

-  CONFN  is  the  name  of  the  configuration 
with  UNTTN_SMAILN;  -  repeat 

-  for  all  source  mail  files 
with  UNITN_TMAILN  -  repeat 

-  for  target  mail  &  post  files 
with  UNITN  -  repeat 

-  for  all  program  units 
procedure  CONFN  is 

begin 

UNTTN.UNTTN_prog;  -  repeat 
-  for  all  program  units 

end  CONFN; 

All  Ada  compilation  units  are  compiled  in  the  follow¬ 
ing  order  Al,  A2,  and  B  (order  of  B1  relative  to  B2  is 
irrelevant).  Changes  in  B  units  affect  only  the  changed 
package  (therefore  changing  connections  between  program 
units  and/or  adding/deleting  program  units  from 
configuration  is  easy  and  simple).  It  is  worthwhile  to  note, 
that  during  compilation  of  a  program  unit  no  knowledge  of 
configuration  in  which  this  unit  will  participate  is  needed. 

4.  MODEL  COMPILER 

The  compilation  of  an  equation  al  specification  into  an 
object  code  consists  of  four  stages:  syntax  analysis, 
semantic  analysis  and  checking,  scheduling  of  program 
events,  and  generation  of  the  program.  The  later  three 
stages,  relevant  to  this  paper,  a  summerized  below. 

Semantic  Analysis  and  Checking: 

The  compiler  translates  the  specification  into  a 
directed  graph  of  data  dependences.  Use  of  data  depen¬ 
dence  graphs  to  optimize  programs,  in  particular  for  parallel 
execution,  has  been  proposed  recently  in  the  literature  (see 
for  example  [Allen  et  al,  1983],  [Ferrante,  Ottenstein.  and 
Warren  1984],  [Kuck  et  al,  1981;  Waters,  1983]).  The  dis¬ 
tinctive  feature  of  the  array  graph  of  the  MODEL  language 
is  the  compact  representation  of  data  dependences  (a  node 
represents  entire  array  not  a  single  element)  and  the  lack  of 
control  dependences  (flow  of  control  is  generated  by  the 
compiler). 


f-w»rtny  the  specification  and  making  corrections 
and  may  be  regarded  as  inferring  or  propagating 

attributes  from  node  to  node.  Thanks  to  nonprocedural 
semantics  of  the  MODEL  language  we  were  able  to  imple¬ 
ment  powerful  consistency  checks  in  the  compiler.  Experi¬ 
ence  has  shown  that  these  checks  are  effective  in  locating 
80-90%  of  the  emirs  (not  including  syntax  errors)  in 
development  of  a  program  (SzymansJd,  et  al,  1984], 

Scheduling  Program  Events: 

In  composing  a  unit  specification  the  user  chooses 
nanml  and  convenient  data  structures  and  equations.  Typi¬ 
cally  this  choice  does  not  correspond  to  the  most 
efficient  implementation.  In  addition,  the  user  descrip¬ 
tion  of  data  is  independent  of  the  medium  of  the  data  and 
whether  it  is  internal  (in  ™in  storage),  external  (secondary 
storage),  or  exchanged  (communication  line  carrying  mes¬ 
sages).  It  is  up  to  the  compiler  to  map  the  user's 
specification  into  an  efficient  procedural  computer  program. 

The  optimization  of  the  schedule  proposed  in  the 
MODEL  compiler  is  based  on  merging  scopes  of  iterations 
to  enable  elements  of  the  same  or  related  structures  to  share 
memory  locations.  Usually  there  are  many  ways  in  which 
components  can  be  merged  (for  different  dimensions),  each 
corresponding  to  different  total  orderings  of  the  component 
graph.  The  memory  requirements  of  different  candidate 
scopes  of  iterations  serves  as  the  criterion  for  selecting  the 
optimal  merging  and  corresponding  total  ordering  of  the 
schedule.  The  selection  is  equivalent  to  NP -complete  prob¬ 
lem  of  finding  a  clique  with  the  maximum  weight  of  nodes 
in  an  undirected  graph.  Therefore  a  heuristic  is  used  [Szy- 
mansJri,  1987]. 

Generating  Ada  Code: 

The  final  step  of  compilation  is  program  generation 
that  translates  the  individual  entries  in  the  schedule  into 
the  object  code.  In  generating  Ada  code,  the  MODEL  com¬ 
piler  heavily  depends  on  the  library  of  generic  procedures 
for  i/o  conversions  and  mathematical  operations.  These  gen¬ 
eric  procedures  are  differently  instantiated  in  the  generated 
programs  according  to  the  data  types  used  in  the 
specification.  The  object  programs  also  use  overloaded 
definitions  of  mathematical  functions  and  operators  to  keep 
them  independent  of  the  used  data  types.  The  generated 
code  use  only  standard  features  of  Ada.  It  can  be  easily 
added  to  the  existing  Ada  software.  It  can  also  be  used  as  a 
pan  of  the  overall  software  development  process. 

5.  CONCLUSION 

The  MODEL  equahonal  language  provides  the  pro¬ 
grammer  with  a  powerful  tool  for  very-high  level,  nonpro¬ 
cedural  development  of  the  executable  system 
specifications.  The  MODEL  compiler  enables  rapid  proto¬ 
typing  and  ensures  high  level  of  correctness  and  con¬ 
sistency  checking.  Ada,  as  an  object  code  for  the  MODEL 


compiler,  provides  an  efficient  implementation  tool  for 
parallel  execution  of  the  equahonal  specifications.  It  also 
ensures  smooth  synthesis  of  automatically  generated  Ada 
code  with  the  existing  Ada  software. 

Use  of  an  equahonal  language  for  expressing  computa¬ 
tions  shields  the  user  from  considering  low  level  implemen¬ 
tation  details,  like  describing  input/output  operations,  loop 
structure,  flow  of  control  in  the  program  etc.  Compilation 
of  specifications,  including  optimization  and  synchroniza¬ 
tion  algorithms  and  customized  code  generators  provides 
the  user  with  efficient  implementations  of  real  time  sys¬ 
tems.  Three  cooperating  components  of  the  MODEL  sys¬ 
tem:  MODEL  compiler.  Configurator,  and  Tuning  Evalua¬ 
tor.  constitute  an  integrated  software  development  system 
that  supports  rapid  prototyping,  modularization  and 
comprehensive  consistency  checking. 
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